Part 1: Generate Network Traffic

In this guided exercise, you will apply what you've learned so far to capture and analyze network traffic using Wireshark.

You will start as they all start, with ping, the “Hello World” of networking. Like the sonar ping of submarines and depth finders, you will bounce some electricity off targets to see if they respond. You will make each host ping every other host in the environment to confirm everyone is online.

Following that, you’ll conduct a file transfer, gain remote access to a machine, and login to a web application – three fairly canonical operations in the world of networking. This should provide a balanced meal for a new wire shark. Time to liven up the wires.

Ready. Set. Go.

1. From the Wireshark menu, select Capture > Options to open the Capture Interfaces dialog box.
   
2. In the Capture Interfaces dialog box, select the h1-eth1 interface, then click Start to begin capturing traffic sent and received by the h1 machine.
   
   When prompted, click Continue without Saving.
   

   

   Note: Don't see the interface you're looking for? Go back to Core Concepts and make sure you're working in the emulated network - not directly on the lab VM.
   
   Typically, captures will be run on network nodes, like switches and routers, rather than endpoints. And these devices are usually configured with a special port that pumps out a copy of (mirrors) every packet that passes through that device, no matter which interface they were received on.
3. Restore the cybrary@clabber terminal.
   
4. At the mininet> prompt, execute pingall to ping every device on the network.
   

   

   Next, you will return to your workstation, h1, from which you’ll be transmitting the rest of your network traffic.
   
5. Restore the "Node: h1" terminal.
   
   In the next steps, we will start with a file transfer.
   
6. In the Node: h1 terminal, execute ftp fileserver to open a connection to the file server in the network.
   
7. At the Name (fileserver:root) prompt, type cybil and press Enter.
   
8. At the Password prompt, type unr3st and press Enter.
   

   

9. At the ftp> prompt, execute ls to view the files in the current directory.
   
   Passwords.txt – yes please. Grab that. Or, in the words of the FTP, ‘get’ that (a command joke…).
   
10. Execute get passwords.txt to transfer the file from the remote fileserver to your local machine.
    

    

    Confirm you get a 226 Transfer complete message. If not, ensure your command was typed correctly.
    
    Next, clean up after yourself – it’s not safe to leave that file hanging around.
    
11. Execute delete passwords.txt to delete the passwords.txt file.
    
12. Execute exit to close your file transfer session with the fileserver.
    
    Next, you will generate traffic related to remote access protocols. For the purposes of this lab, you will use a primitive remote access protocol called telnet.
    
    In practice, you should use a secure connection protocol like SSH so that your communication with the remote server is encrypted. Telnet delivers data in plaintext, so anyone sniffing the wires can see your every move. Poor security, but excellent for demonstrations.
    
13. At the root@clabber prompt, execute telnet utilserver to initiate a telnet connection to the utility server in your topology.
    
14. At the login: prompt, type tuser as your username and press Enter.
    
15. At the password prompt, type tugood as your password and press Enter.
    
16. At the $ prompt, execute pwd to print the current working directory to the console.
    
17. At the $ prompt, execute ls to list files in this directory.
    
    Look, a servers.txt to go with your passwords.txt. Let’s see what’s in it.
    
18. At the $ prompt, execute cat servers.txt to print the contents of the servers.txt file.
    

    

    Tasty! No need to bring that with you – Wireshark will remember the details, so go on and get out of this telnet session.
    
19. Execute exit to end your telnet session.
    
    That was fun, let’s do it one more time, but just a quick log-in and exit. This will provide fodder for demonstrating how Wireshark can distinguish different sessions.
    
20. Repeat steps 13-15.
    
21. Execute exit to end your second telnet session and return to the root@clabber prompt.
    
    In the next steps, you will generate some web traffic - your window to the wide and wondrous digital world, the second best place to catch some malware (the first being your inbox… silly humans, love to click stuff).
    
22. At the root@clabber prompt, execute firefox to open a web browser.
    
    This may take up to 30 seconds. You can disregard any warnings that appear in the terminal.
    
23. In the browser location bar, type http://webserver.com and press Enter to head to the webserver in the topology.
    

    

    No affiliation to the Internet-accessible webserver.com. This is a local webserver in your topology.
    
24. Click the Click here to log in link.
    
25. Enter the following credentials in their corresponding fields:
    
    Username: esper
    Password: psybrary
    
26. Click the Login button to complete the login.
    

    

    What?! A file downloaded, one called ComputerCleaner.elf? Bet that title is ironic. Unfortunately, you can’t check it out because it looks like it was immediately deleted. Looks like a case of “user downloads bad file, panics, deletes, and hopes no one brings it up.” Well, that’s going to make it difficult for the forensics team… jk, your capture will make that a cinch.
    
    Go ahead and log out – that’s plenty of traffic for your purposes. Don’t forget to save your capture like a good wire shark! That’s some helpful forensic or diagnostic information you have there—ensure it gets recorded. Then, head over to the analysis phase to see what you can see.
    
27. Click the Click here to log out link, then close the browser.
    
28. Restore the Wireshark window.
    
29. On the Wireshark toolbar, click the red square icon to stop your capture.
    

    

30. From the Wireshark menu, select File > Save As… to save your capture.
    
    Name it however you like. Now go look at what you did.

Part 2: Analyze Network Traffic

It’s not often you will be looking through packets in a live capture. Analysis is usually conducted after the fact, such as a SOC Analyst reviewing a capture file to investigate an alert generated by their Intrusion Detection or Prevention System (IDS/IPS). That computer whiz in popular media, lines of program output racing by on their computer screen? They’re just waiting for the execution to complete before consulting the logs. Wait until you’ve captured a full transcription of the network activity, then you can review it on-demand.

1. In the Wireshark display filter, type icmp and press Enter.
   

   

   ICMP is the protocol that ping speaks, so this filter is showing that radical ping party you started your traffic generation session with.
   
   You can also use some common logical operators in your filter expressions to include multiple types of traffic.
2. In the Wireshark display filter, change your filter expression to the following and press Enter:
   
   icmp or arp
   

   

   ARP is a way of discovering the MAC address of a host with a given IP. You need to know the target’s MAC address for delivery on a local network, so you should only see ARP traffic for hosts in your network (192.168.1.0). Meanwhile, the ICMP shows delivery to several networks (172.16.0.0 and 10.0.0.0).
   
   Looking at ARP traffic is a good way to discover all live hosts on a network. Close analysis of these packets can lead to discoveries of nefarious behaviors such as MAC spoofing, MITM attacks, and NAC (Network Access Control) failures.
   
   Next up: remote access.
3. In the display filter, change the expression to telnet to view all telnet traffic.
   

   

   Remember, you had two telnet sessions here. Can you tell which is which? Wireshark can, using Streams. You could filter for streams by entering an expression into the filter bar, but Wireshark makes it easy for you.
   
4. In the Packet List pane, right-click on the first packet in the list, then select Follow > TCP Stream to view only the telnet packets related to your first session.
   

   

   Woah, look at this – a full record of that initial exchange you had with utilserver. Wireshark colors client transmissions in red and server transmissions in blue to make exchanges easy to follow.

   

   Here you can see the credentials you used to login, the commands you issued, and even the contents of the server.txt file you checked out while you were there! You will also notice that each letter you input in the terminal was echoed by the server (e.g., your username: ttuusseerr). This is because the characters were received by the server, then echoed in your terminal so you could see what you were typing. An exception is your password: if you recall, the characters were not displayed in your terminal, so each letter is only seen once here.
   
5. Close the Follow TCP Stream window.
   
   Streams allow you to view specific sessions between hosts. Wireshark carves out packets related to individual sessions by looking at information like Source and Destination addresses, as well as flags set in the packet that indicate the beginning of a connection (a SYN flag) and the end of a connection (FIN or RST). If you look at the Info column in the Packet List, you should see a [SYN] packet at the top of the list. At the bottom, you should see a [FIN] packet. Furthermore, you should see Wireshark has colored these SYN and FIN packets as a visual aid for demarcating the beginning and end of this stream.
   
   You will also notice that after filtering this stream, you can see fewer telnet packets. This operation excluded that second telnet session of yours. Neat!
   
   Now that you’ve seen Streams, it's time to check out Conversations.
   
6. In the display filter, click the X icon on the right to remove your current filter expression.
   
7. Select any packet with 192.168.1.1 (the address of h1) in the Source column and 172.16.0.1 (the address of webserver) in the Destination column.
   
8. Right-click the selected packet and select Conversation Filter > IPv4 from the context menu.
   

   

   Look at the filter display—all Wireshark did was say “group all packets that contain both of these IP addresses.” As you can see, Conversations are Wireshark’s way of grouping all traffic passed between two endpoints, regardless of individual sessions or protocols.
   
   Some protocols are connection-less, so they don’t use SYN and FIN flags to start and end sessions. In those cases, it’s useful to begin with a Conversation, and then filter the display to only the target protocol. One example of a connection-less protocol is the familiar HTTP. Let's look at that next.
   
9. In the display filter, append the following to the current filter expression and press Enter:
   
   and http
   
   This shows any HTTP traffic exchanged by the two hosts in this conversation. Find an HTTP packet and follow that stream to see where it gets you.
   
10. Select and right-click any HTTP packet, then select Follow > HTTP Stream from the context menu.
    
    Each request for a website is met with a response, and that’s the extent of HTTP in the stream. A total of one exchange—as we said, connection-less. However, it’s still handy to get the exchange in your stream window for easy reading. Remember, client request is red, server is blue: can you tell what type of Server is running on webserver?
    
    Take note of the version of Python listed here. You'll need it to answer one of the questions on the Tasks tab.
    
11. Close the Follow HTTP Stream window.
    
    Next, you will try out some other HTTP filters. You logged into that web application, so if HTTP is connection-less, how does the web application recognize you?
    
    Cookies. Yum.
    
12. In the display filter, replace the current filter expression with http.cookie.
    

    

    Here are all packets that contain the HTTP cookies. A session cookie was added to your browser as a form of identifying you with each request, and will be a jumble of alphanumeric characters. But this application also added an additional cookie in plain english, and wasn’t removed when you logged out (pesky trackers…). Can you spot it?
    
    Hint: Expand the Hypertext Transfer Protocol line for each packet and look for the line beginning with Cookie.
    
    Take note of the cookie (it's wrapped in {brackets}). You will need this information to answer one of the questions on the Tasks tab.
    
    You can double-click on a packet to reveal its contents in a dedicated window. Check out a couple packets and see if you can find this human-readable cookie. Remember that Wireshark groups the packets in the order they were received. Since this cookie wasn’t removed at logout (but the session cookie was), check out a packet that came after the /logout request.
    
    Speaking of unwelcome injections, didn’t that site push a file download to your computer that was quickly deleted? No problem – Wireshark lets you reconstitute this file from the packet data.  I mean, why wouldn’t it, when you’ve captured all the bytes passing through the wire?
    
    One exported file coming up, hot off the wire.
13. From the Wireshark menu, select File > Export Objects > HTTP to open the Export dialog box.
    

    

    No filter required – this view shows a list of data objects transferred with HTTP. One of those objects looks juicy, why don’t you pull that one down and take a closer look.
    
14. In the Export dialog box, select the HTTP object with a Filename of download, then click Save.
    
15. In the Save Object As... dialog box, click Save to save the file with the default name.
    
    Let’s check out your pull!
    
16. On the docked menu at the bottom of the screen, click the Folder icon on the right side, then select h1 > Open Folder.
    

    

17. Double-click the file called download to get a closer look at your loot.
    
    Score! Unfortunately, Harold’s pain can’t be hidden when a wire shark is on the job. Take note of the last two words in this image. You will need this information to answer one of the questions on the Tasks tab.
    
    Last step – time to review your file transfer. Return to the Wireshark window and close the Export dialog box.
    
18. In the display filer, replace the current filter expression with ftp and press Enter.
    
19. Select and right-click any packet and select Follow > TCP Stream from the context menu.
    

    

    As before, the full exchange is recounted in red and blue transmissions. A neat ledger that contains the username and password in cleartext, as well as the files that were transferred.
    
    But what about the contents of the file? You can see that, too. You just need a different filter, because FTP uses a separate channel for transferring the content of files.
20. Close the Follow TCP Stream window.
    
21. In the display filter, replace the current expression with ftp-data and press Enter.
    
22. Select and right-click the packet that lists passwords.txt in the Info column, then select Follow > TCP Stream from the context menu.
    
    Jackpot! You shark, you.

Up Next

If you’re curious about the other available Wireshark filters, check out the following cheat sheet: https://www.stationx.net/wireshark-cheat-sheet.

You’ll also find a Wireshark Command Generator where you can describe what you’d like Wireshark to do in plain English and have that request converted into a ready-to-use Wireshark display filter. Neat!

Now that you’ve had some guided practice and grown your baby wire shark teeth, it’s time to conduct some packet analysis on your own. We’ll provide a capture file for you to sink your teeth into.